home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Netware Super Library
/
Netware Super Library.iso
/
nov_info
/
nw386
/
append-c.386
< prev
next >
Wrap
Text File
|
1989-07-24
|
8KB
|
183 lines
Appendix C
Benchmarking NetWare 386
Because of NetWare 386's modular design and its
capability to allocate and deallocate memory as needed,
it is naturally more open and efficient. However, in
light of these new, standard-setting features, it might
be easy to take for granted the fact that NetWare 386 is
a specialized networking operating system designed and
coded to give optimum speed and performance. For
example, such things as reads and writes to the server
hard disk are as fast or faster than reads or writes to
a local disk. Although benchmarks verify these and other
performance issues, at least three factors particular to
NetWare 386 must be accounted for during benchmarking.
If not, the benchmarks will not reveal the true
performance capabilities of NetWare 386. These three
factors are as follows:
■ Memory Allocation: Let the NetWare 386 system
allocate the memory it needs to meet the
benchmarking test parameters. To do this, run the
test once or twice before recording results.
■ Read-after-Write Verfication: Turn off this NetWare
386 automatic feature. When benchmarking NetWare
against a system that does not perform read-after-
write verification, these extra reads (if not
disabled) put NetWare at a disadvantage.■Salvagable Files: Turn off this NetWare 386
automatic feature. By default, this feature
prevents deleted files from being purged so they
can be salvaged if necessary. If this feature is
not disabled, benchmarking NetWare against a system
that does purge deleted files puts NetWare at a
disadvantage. To disable this feature, set the
Immediate Purge of deleted files = ON
Memory Allocation
In versions of NetWare before 386, supervisors and system
administrators allocated memory during installation for
such resources as routing buffers, file and directory
handles, and so forth. The amount of memory allocated
to these resources remained set while the remaining
memory went to cache. NetWare 386, however, requires
about 2MB of memory for the initial OS, while the
remaining memory becomes a pool of cache buffers to be
dynamically allocated by resources as needed. As NetWare
386 begins running, it allocates memory from this pool
of cache buffers for any of the following resources:
■ Directory cache buffers
■ File service processes
■ Turbo FAT
■ FAT
■ Routing buffers
■ Disk elevator size
■ Directory hash tables
■ Router/server advertising memory
■ Maximum number of open files
■ File locks
■ Kernel processes
■ Kernel semaphores
■ TTS transactions
■ NetWare Loadable Modules (NLMs)
Dynamic memory allocation allows the number of cache
buffers needed for any of these resources to grow
according to demand. For example, cache buffers for
Directory Table blocks are allocated according to demand,
cache buffers for Turbo FATs are allocated when another
file needs to be indexed, and so on.However, NetWare dynamic memory allocation also features
a system of checks and balances. Since dynamically
allocated memory is never returned to the cache buffer
pool unless the server goes down, these values are not
allowed to grow without restriction. Although the number
of server processes and the memory required for those
processes grow to meet demand, the server does not spawn
a process immediately upon demand.
Instead, the server waits a few seconds to see if an
existing process becomes available to service the demand.
If so, the server does not spawn a new process. This
restriction on growth ensures that the server does not
permanently allocate memory because of sudden, infrequent
peaks of server activity.
To summarize, NetWare 386 provides dynamic memory
allocation for network resources. However, depending on
the number of resources that require memory and how much
memory each resource requires, the dynamic memory
allocation may take some time. During this time, the
NetWare 386 system may not be running at peak efficiency
or speed. When preparing to do benchmarks then, the
NetWare 386 system should run a while before the
benchmarking begins. A good rule of thumb is to run the
benchmarks a couple of times before tracking performance
numbers.
Read-after-Write Verification
Another factor to consider during benchmarking, read-
after-write verification, has to do with matching
functionality in the operating systems being tested.
NetWare 386 automatically performs a read-after-write
verification on each piece of information written to the
disk. If the read-after-write is unsuccessful after
several attempts, that disk block is marked as bad, and
a feature of NetWare 386 called HotFix automatically
writes the data to another part of the disk.
During a performance test in which you do a large number
of writes to disk, NetWare 386 (with read-after-write
verification) would be at a disadvantage against another
system running without read-after-write verification.
To disable NetWare 386 read-after-write verification, go
to the server console and, at the console prompt, type
the following:
SET ENABLE DISK READ AFTER WRITE VERIFY = OFF
Salvage Files
As with read-after-write verification, Salvage Files, is
a feature that could put NetWare 386 at a disadvantage
during benchmarking. NetWare 386 treats deleted files
differently than did previous versions of NetWare. In
previous versions, a user could only recover the file (or
files) deleted in the last ERASE or DELETE command.
Files deleted in earlier delete commands were lost
forever. NetWare 386 saves deleted files (and all
information about those files) in their default directory
until the server runs out of disk allocation blocks on
the volume or until the user deliberately purges the
deleted files. If the user deletes the file's default
directory too, the file is saved in a DELETED.SAV
directory located in the volume's root directory.
In a testing environment in which you create and delete
a large number of files in the same area over and over
again, the NetWare 386 Salvage Files feature can
adversely affect the dynamics of caching. For example,
when an operating system does not save a deleted file,
it reallocates the space for that file to the next write.
It also makes the cache space for that deleted file
available. Thus, when the tests are run over and over
again, the operating system allocates the same disk
blocks and cache buffers over and over to perform the
benchmarks.
Since NetWare 386 saves each deleted file, it must
traverse the disk to perform the large repetition of
writes that you do during benchmarking, reallocating a
new disk block for each newly created file written to the
disk. This also means that cache buffers are taken away
to create a new disk block. Cache buffers are also
flushed to disk and must be again added to cache for the
next test. So caching is really not being used as it
ought to be.
If you are testing NetWare 386 against an operating
system that does not save deleted files, disable the
NetWare 386 Salvage Files feature. To do this, type the
following at the server console prompt:
SET IMMEDIATE PURGE OF DELETED FILES = ON
When you set deleted files for immediate purging, you
gain two things. First, NetWare 386 won't have to
reallocate new disk blocks for the files it has in
memory, and second, it can make more efficient use of its
caching capabilities.